home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19941031-19941221 / 000195_news@columbia.edu_Sun Nov 20 04:58:34 1994.msg < prev    next >
Internet Message Format  |  1995-07-31  |  2KB

  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA07390
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sun, 20 Nov 1994 13:25:06 -0500
  3. Received: by apakabar.cc.columbia.edu id AA19892
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sun, 20 Nov 1994 13:25:04 -0500
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!news.kei.com!newshost.marcam.com!usc!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc,alt.winsock
  8. Subject: Re: winsock/pkt dvr hack possible?
  9. Message-Id: <1994Nov20.105834.33349@cc.usu.edu>
  10. Date: 20 Nov 94 10:58:34 MDT
  11. References: <3a67j8$j39@Mercury.mcs.com> <Pine.SUN.3.91.941118031532.9000A-100000@soleil> <3aiudg$pil@apakabar.cc.columbia.edu> <3anvci$dut@relay.tor.hookup.net>
  12. Organization: Utah State University
  13. Lines: 26
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:1140 alt.winsock:22429
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <3anvci$dut@relay.tor.hookup.net>, bangus@hookup.net (Brian F. Angus) writes:
  18. > In article <3aiudg$pil@apakabar.cc.columbia.edu>, jaltman@watsun.cc.columbia.edu 
  19. > says...
  20. >>A packet driver on top of winsock makes no sense since winsock is not 
  21. >>protocol independent.  The best you could possibly hope for would be a 
  22. >>Telnet redirector for Windows DOS Sessions which communicates through 
  23. >>WinSock.
  24. > Actually, it could probably be done by filtering out the non TCP/IP
  25. > functionality, but it would be a very complicated bit of engineering.
  26. > You would likely have to write some nasty DOS interrupt redirection
  27. > code which would allow the DOS program to communicate directly to a native Windows 
  28. > WINSOCK application via the packet driver interrupt.  The WINSOCK application 
  29. > would act as a type of pass-through tunnel for the DOS application.  This may 
  30. > require the use of a custom VXD, I'm not sure.  I briefly looked into this but I 
  31. > have decided that my skill sets are not quite at a level required for this task.
  32. -------
  33.     Jeff is correct. The top of a sockets API is a TCP stream channel of
  34. bytes, not packets. "It could be done..." means creating a second TCP/IP
  35. stack feeding from the streams channel and packaging it into TCP/IP over
  36. Ethernet frames to be passed to the application. Not very desirable, nor 
  37. realistic.
  38.     Joe D.